1. Field of the Invention
The present invention relates to computer systems. More particularly, the present invention relates to moving set data communications.
2. Background
A virtual machine is an abstract computing machine generated by a software application or sequence of instructions that is executed by a processor. The term xe2x80x9carchitecture-neutralxe2x80x9d refers to programs, such as those written in the Java(trademark) programming language, which can be executed by a virtual machine on a variety of computer platforms having a variety of different computer architectures. Thus, for example, a virtual machine being executed on a Windows(trademark)-based personal computer system will use the same set of instructions as a virtual machine being executed on a UNIX(trademark)-based computer system. The result of the platform-independent coding of a virtual machine""s sequence of instructions is a stream of one or more bytecodes, each of which is, for example, a one-byte-long numerical code.
The Java(trademark) Virtual Machine is one example of a virtual machine. Compiled code to be executed by the Java(trademark) Virtual Machine is represented using a hardware- and operating system-independent binary format, typically stored in a file, known as the class file format. The class file is designed to handle object oriented structures that can represent programs written in the Java(trademark) programming language, but may also support is several other programming languages. The class file format precisely defines the representation of a class or interface, including details such as byte ordering that might be taken for granted in a platform-specific object file format. For the sake of security, the Java(trademark) Virtual Machine imposes strong format and structural constraints on the instructions in a class file. Any language with functionality that can be expressed in terms of a valid class file can be hosted by the Java(trademark) Virtual Machine. The class file is designed to handle object oriented structures that can represent programs written in the Java(trademark) programming language, but may also support several other programming languages. The Java(trademark) Virtual Machine is described in detail in Lindholm, et al., xe2x80x9cThe Java(trademark) Virtual Machine Specificationxe2x80x9d, April 1999, Addison-Wesley Longman, Inc., Second Edition.
Resource-constrained devices are generally considered to be those that are relatively restricted in memory and/or computing power or speed, as compared to typical desktop computers and the like. By way of example, other resource-constrained devices include cellular telephones, boundary scan devices, field programmable devices, personal digital assistants (PDAs) and pagers and other miniature or small footprint devices.
Smart cards, also known as intelligent portable data-carrying cards, are a type of resource-constrained device. Smart cards are made of plastic or metal and have an electronic chip that includes an embedded microprocessor or microcontroller to execute programs and memory to store programs and data. Such devices, which can be about the size of a credit card, have computer chips with 8-bit or 16-bit architectures. Additionally, these devices typically have limited memory capacity. For example, some smart cards have less than one kilo-byte (1K) of random access memory (RAM) as well as limited read only memory (ROM), and/or non-volatile memory such as electrically erasable programmable read only memory (EEPROM).
A Java(trademark) virtual machine executes virtual machine code written in the Java(trademark) programming language and is designed for use with a 32-bit architecture. It would be desirable to write programs that use the full implementation of the Java(trademark) Virtual Machine for execution on resource-constrained devices such as smart cards. However, due to the limited architecture and memory of resource-constrained devices such as smart cards, the full Java(trademark) Virtual Machine platform cannot be implemented on such devices. Accordingly, a separate Java Card(trademark) (the smart card that supports the Java(trademark) programming language) technology supports a subset of the Java(trademark) programming language for resource-constrained devices.
Turning now to FIG. 1, a typical apparatus for installing applications on a Java Card(trademark) technology enabled device 120 is presented. In Java Card(trademark) technology, a Java Card(trademark) converter 100 takes regular class files 105 as input and converts them to a CAP (converted applet) file 110. The CAP format supports a subset of the class file information. Each CAP file 110 contains all of the classes and interfaces defined in one Java(trademark) package. After conversion, the CAP file 110 is copied to a card terminal, such as a desktop computer with a card reader peripheral. Then an installation tool 115 on the terminal loads the CAP file 110 and transmits it to the Java Card(trademark) technology enabled device 120. An installation application 125 on the Java Card(trademark) technology enabled device 120 receives and processes the data from the terminal to install the application on the Java Card(trademark) technology enabled device 120.
Due to resource-constrained nature of a typical Java Card(trademark) technology enabled device 120, only a relatively small amount of memory is available for data communication. Thus, the communication between the terminal and the Java Card(trademark) technology enabled device 120 typically consists of multiple application data units (APDUs) 135 sent from the terminal to the Java Card(trademark) technology enabled device 120. An APDU 135 is data packet having a data portion that ranges in size from 32 bytes to 256 bytes. Data that is sent from the terminal is encapsulated in one or more APDUs 135 before being sent to the Java Card(trademark) technology enabled device 120.
Since the size of the multiple data values encapsulated varies, the data values are frequently split between multiple APDUs 135. Table 1 illustrates the data portion of an APDU 135. Table 2 shows data to be encapsulated in an APDU 135.
If the data shown in Table 2 were encapsulated in an APDU 135 represented by Table 1 while preserving the relative order of the data, there would be insufficient room for the second sixteen-bit integer, resulting in a xe2x80x9cdata splitxe2x80x9d problem. This data split problem is typically handled by processing the data on the terminal side to guarantee the data will not be split. This processing on the terminal side may include by way of example, changing the size of the APDU 135 to prevent a data split, or reordering the data within APDUs before sending them to a Java Card(trademark) technology enabled device 120. Each of these solutions has disadvantages.
Changing the size of the APDU 135 and reordering the data within the APDU 135 requires complex negotiation between the terminal and the card. The terminal must transform the data and provide the card with enough information to reconstruct the data. The card must receive the information from the terminal, reconstruct the data and provide a response to the terminal. Making the terminal and card applications data-dependent as such increases processing overhead. This data dependency also increases memory overhead, both in terms of program size and the amount of RAM required to store buffered data.
Putting intelligence on the terminal side also raises security concerns. Knowing whether a data split problem exists requires that the terminal know the size of each data item being sent. This size information is related to the data type. This information is not available if the data is encrypted. Thus, the terminal must decrypt encrypted data before it interprets the data to determine the size of each data unit. Once the data is decrypted, the terminal has access to private information. In some applications, only the card is meant to interpret the data, not the terminal.
Accordingly, a need exists in the prior art for a method and apparatus for data communications between a terminal device and a smart card that requires relatively little processing and memory overhead on terminal and smart card applications. A further need exists for such a method and apparatus that is relatively secure.
A method for data communication includes receiving a data packet that includes at least one contiguous data item, defining a window that initially includes the beginning of the data items, determining whether the window includes a part of a split data item and processing the contiguous data items when there are no split data items. The method also includes processing all data items occurring before a split data item when a split data item is found, storing the first part of a split data item, moving the window to include both parts of the split data item, appending the stored first part to the second part to create an appended packet and processing the appended packet. An apparatus for data communication includes at least one memory having program instructions and at least one processor configured to use the program instructions to receive a data packet that includes at least one contiguous data item, define a window that initially includes the beginning of the data items, determine whether the window includes a part of a split data item and process the contiguous data items when there are no split data items. The processor is also configured to process all data items occurring before a split data item when a split data item is found, store the first part of a split data item, move the window to include both parts of the split data item, append the stored first part to the second part and process the result.